The embodiments of the present invention relate to the field of communication networks and in particular of network time distribution.
Precision Time Protocol (PTP) (also called as IEEE1588 protocol) and especially PTPv2 (release 2) appears to be a widely used protocol to distribute precise time.
In this document, the term “PTP” refers for example to PTP or to PTPv2.
As a timestamp packet protocol, PTP performance typically depends on two network parameters:
a Packet Delay Variation (PDV) which is the difference of the transmission delay of an observed packet with respect to a reference transmission delay (e.g. theoretical minimum delay)
a Delay Asymmetry which is the difference between transmission delays in the master-slave direction and in the slave-master direction.
Both parameters greatly depend on the transport network path used to convey the PTP flow.
In practice, the values of said parameters are set at the establishment of the transport network path.
However, in case of a PTP failure, there is typically no communication between PTP entities and network entities, and therefore no mechanism, at PTP level, exists allowing to trigger a protection procedure to use a protection path.
Similarly, in case of a path change at the network level (due to a transport network failure for example), there is no mechanism to inform the PTP slave clock of the new network characteristics (e.g. in term of delay asymmetry) related to the new transport network path. In order to solve this problem, some solutions of the state of the art consist on the one hand in a manual solution wherein an operator performs updates making use of different management entities, including the network and PTP management; and on the other hand in a unified management combining PTP management system and network management system.
However, the manual solution typically induces a high OPEX (operational expenditure) and a high reconfiguration time which requires stable (and therefore expensive) slave clocks. Concerning the unified management, due to its slowness (due to the numerous supervision tasks launched on it), the management server is typically not adapted for real-time procedure required in a network protection/reconfiguration context (which can lead to high recovery times). This solution is typically not scalable for a large network.